Zero-Downtime Database Migration: Amazon RDS Blue/Green Deployments Guide

1-Line Summary

Amazon RDS Blue/Green Deployments provision a fully isolated staging environment (Green), synchronize data via logical replication, and swap DNS endpoints atomically with under 1 minute of write downtime.

1. Why In-Place Upgrades Risk Service Availability

Performing an in-place major version upgrade (e.g., MySQL 5.7 to 8.0) directly on an active database instance triggers internal data dictionary rebuilds and schema migrations, resulting in 30+ minutes of unplanned downtime with no immediate rollback path.

[RDS Blue/Green Deployment Workflow]
Production Traffic
       │
       ▼ (DNS Endpoint: mydb.c7xxxx.ap-northeast-2.rds.amazonaws.com)
┌──────────────┐                          ┌──────────────┐
│ [Blue DB]    │ ──(Logical Replication)─>│ [Green DB]   │
│ MySQL 5.7    │   (binlog_format = ROW)  │ MySQL 8.0    │
└──────────────┘                          └──────────────┘
   (Current Prod)                            (Target Staging)

---

2. Step-by-Step Execution SOP

Step 1. Parameter Group Prerequisites

Binary logging is required for logical replication. Configure a custom parameter group before initiating deployment:

# Static parameters (Requires manual instance reboot)
binlog_format = ROW
binlog_row_image = FULL

Step 2. Provision & Validate Green Environment

Create the deployment via AWS CLI and run read-only benchmark queries against the Green instance to verify sql_mode and execution plans:

aws rds create-blue-green-deployment \
    --blue-green-deployment-name bg-mysql8-upgrade \
    --source "arn:aws:rds:ap-northeast-2:123456789012:db:prod-mysql" \
    --target-engine-version "8.0.36"

Step 3. Atomic Switchover

Once Replication Lag drops to 0 seconds, execute the switchover:

aws rds switchover-blue-green-deployment \
    --blue-green-deployment-identifier bgd-xxxxxxxxx \
    --switchover-timeout 30

• Endpoint Swapping: AWS blocks write traffic to Blue, drains replication buffers, and swaps CNAME endpoints between Blue and Green. Total service disruption is typically under 30 seconds.

---

3. Gotchas & Engineering Checkpoints

1. Static Parameter Reboots: Changing binlog_format is a static modification requiring an initial maintenance reboot on the source instance.
2. Primary Key Requirement: Tables without a Primary Key trigger severe row-by-row table scans during logical replication, creating runaway replication lag.
3. Instant Rollback Safety Net: After switchover, the old Blue database remains intact in a read-only state, preserving a zero-data-loss rollback option.

---

Published: 2026-07-23 23:22:25Updated: 2026-08-15 13:57:00